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Remarks 

As stated above, Applicants appreciate the Board's consideration of Applicants' appeal 
and request reexamination and reconsideration of the subject application in view of the following 
remarks. 

In the subject application, as of the Final Office Action dated October 10, 2006, claims 1- 
15 were pending, of which claims 1, 3, 8, 9, 10, 13, and 15 are independent claims, and claims 2, 
4-7, 11-12, and 14 are dependent. With this amendment, Applicants have amended claims 1, 3, 
9, 10, 13, and 15. Further, Applicants previously cancelled claims 8, 11, 12, and 14. Applicants 
respectfully submit that no new matter is believed to have been added as a result of this 
amendment. 



Claim Rejections - 35 U.S.C. § 101 

Claims 1-7, 9, 10, 13, and 15 stand rejected under 35 U.S.C. § 101 as being directed 
towards non-statutory subject matter. More specifically, the Board has rejected claims 1-7, 9, 
10, 13, and 15 because the Board appears to believe that claims 1-7, 9, 10, 13, and 15 are not tied 
to a particular "machine" and do not "transform" underlying subject matter. See the decision, 
pages 5-6. Applicants respectfully traverse this rejection. 

Applicants have amended claim 1 to include the limitation "said web site residing in a 
memory of a web server and including a place comprising a plurality of subrooms, each 
subroom being an independent entity belonging to said place said web server including an 
HTTP server interfaced with the Internet". See Applicants' amended claim 1, emphasis 
added. Support for Applicants' amendment to claim 1 may be found at least at pages 23, 24, and 
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30-32, and Figure 3 of the specification, as filed. The relevant portions of these pages and 

Figure 3 are provided below, for the Examiner's convenience: 

Exemplary Server/Client System 

By way of background, Figure 4 illustrates the system architecture for an 
exemplary server 105 or client computer 101, such as an IBM THINKPAD 701® 
computer or like computer, on which a network access system can be implemented. The 
exemplary computer system of Figure 4 is discussed only for descriptive purposes, 
however, and should not be considered a limitation of the invention. Although the 
description below may refer to terms commonly used in describing particular computer 
systems, the described concepts apply equally to other computer systems, including 
systems having architectures that are dissimilar to that shown in Figure 4. 

The server 105 or client 101 computer includes a central processing unit (CPU) 
116, which may include a conventional microprocessor, random access memory (RAM) 
117 for temporary storage of information, and read only memory (ROM) 118 for 
permanent storage of information. A memory controller 113 is provided for controlling 
system RAM 117. A bus controller 114 is provided for controlling bus 111, and an 
interrupt controller 115 is used for receiving and processing various interrupt signals 
from the other system components. 

See the subject application, as filed, pages 23-24. 



Web Server Cache 

Figure 3 is a block diagram of a web server system having a caching system useful 
in connection with the preferred embodiments of the present invention, and is an 
example of a domino server without QuickPlace shown. As will be described more fully 
hereafter, QuickPlace allows a user at browser 101 to use a default website and from that 
as a manager to set security, pop up a window, add reader/author, distribute notifications 
and passwords to control access, create a room which gives options for customizing 
color scheme, control access to the room, create sub room down as many layers down, 
with each subroom selectively inheriting characteristics of a previous room, and 
changing these characteristics. 

As shown in Figure 3, the web server 132 may be connected to a number of 
Domino sources 142. However, the sources may comprise any number of different types 
of elements, other than Domino databases: other databases, files, other web sites, etc, but 
Domino sources are shown for clarity. The web server may also be connected to HTML 
databases 139 as was discussed above. The web server 132 comprises and is associated 
with many functional units. It comprises the HTTP server 134, discussed above, which 
comprises a TCP/IP application 157, and a HyperText Transfer Protocol (HTTP) unit 
156. The web server 132 further comprises the HTML converter unit 136 discussed 
above. It further comprises a parser 145 (for parsing received URLs), a cache 143, 
cache control unit 144, and operates in cooperation with a cached-response analyzer 146, 
and a database server 137, including a response builder 154, a source access unit 155, 
and a cacheability analyzer 149. 
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These units operate as follows: TCP/IP unit 157 and HTTP unit 156 act together 
as the interface to the Internet by implementing the TCP/IP and HTTP protocols for 
server 132. TCP/IP unit 157 utilizes the TCP/IP protocol for conveying and receiving 
information to and from the Internet. HTTP unit 156 implements HTTP, which is the 
standard on which the Web operates. These two units provide the full-service interface 
to the Web. 



See the subject application, as filed pages 30-32. 




See the subject application, as filed, Figure 3 
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As such, Applicants respectfully submit that claim 1 is tied to a particular machine, 
including a "web site residing in a memory of a web server" and "said web server including an 
HTTP server interfaced with the Internet." See Applicants' amended claim 1. Therefore, 
Applicants respectfully submit that claim 1 is directed towards statutory subject matter. Since 
claim 2 depends from claim 1, Applicants respectfully submit that claim 2 is directed towards 
statutory subject matter as well. Further Applicants have amended independent claims 3, 9, 10, 
13, and 15 to include similar limitations to that of amended independent claim 1. Therefore, 
Applicants respectfully submit that those claims are directed towards statutory subject matter as 
well. Moreover, since claims 4-7 depend, either directly or indirectly, from independent claim 3, 
Applicants respectfully submit that those claims are directed towards statutory subject matter 
also. Accordingly, withdrawal of the rejection to claims 1-7, 9, 10, 13, and 15 under 35 U.S.C. § 
101 is respectfully requested. 

Prior Claim Rejections - 35 U.S.C. §103 

The Examiner previously rejected claims 1-7, 9, 10, 13, and 15 under 35 U.S.C. § 103, 
however the Board vacated this rejection. See the decision, pages 2 and 7. Applicant 
respectfully maintains the arguments submitted on appeal regarding this rejection, as the Board 
did not address this rejection in the decision. Applicant's argument is set forth below. 

Rejection of Claims 3-7, 9, 13 and 15 Under 35 U.S.C. 103 

Claims 3-7, 9, 13, and 15 have been rejected under 35 U.S.C. 103(a) over Salas et al 
(Salas, U.S. Patent 6,233,600) in view of Maurille (U.S. Patent 6,484,196) and further in view of 
Cutler et al. (U.S. Patent 5,129,083). 
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As stated by the Federal Circuit, a prior art reference must disclose the elements of the 
claimed invention "arranged as in the claim." The Examiner, further, must identify the elements 
of the claims of the application, determine their meaning in light of the specification and 
prosecution history, and identify the corresponding elements disclosed in the reference. [See 
Lindermann Maschinenfabrik GmbH v. American Hoist & Derrick Co., 221 USPQ 481, 485 
(Fed. Cir. 1984). This case dealt with anticipation under 35 U.S.C. 102, but the principle applies 
here as well]. Further, references do not teach when the prior art is lacking or missing a specific 
feature or structure of the claimed invention. [See Continental Can Co. USA v. Monsanto Co., 
20 USPQ 2d 1746, 1748 (Fed. Cir. 1991)]. 

The proper approach to the obviousness issue must start with the claimed invention as a 
whole. It is true that it consists of a combination of old elements so arranged as to perform 
certain related functions. It is immaterial to the issue, however, that all of the elements were old 
in other contexts. What must be found obvious to defeat the patent is the claimed combination. 
[Kimberly-Clark Corp. v. Johnson & Johnson, 745 F.2d 1437, 223 USPQ 60-3, 609-10 (Fed. Cir. 
1984).] 

Applicant will show that several of the elements in the claims alleged by the Examiner to 
be taught by the references are, in fact, not taught when properly considered, and that when 
considered as a whole, the cited art references do not teach the claimed combination. 

In order to find teachings in the art for the method and structure set forth in the claims, 
the Examiner selects (1) Salas from the collaborative workspace technology, (2) Cutler from the 
ACL security technology, and (3) Maurille from the hierarchical data structure technology. 

Referring to (1) collaborative workspace technology, (2) ACL security technology, and 
(3) hierarchical or tree data structure technology, the Examiner states: 
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"Any combination of these three technologies would have been obvious to one skilled in 
the art in 1999." [Emphasis added. Office Action, 10/10/06, page 3.] 

Applicant argues that to read these technologies on "any combination", including 
applicants claims, requires impermissible hindsight using applicant's own claim as a roadmap, 
and that is what the Examiner has done. This "any combination" statement fails to establish why 
these references "would appear" to have been combined. 

Applicant notes the following critical distinctions from each of the references, and from 
their combination. These distinctions further establish the conclusion that the referenced 
elements in the combination suggested do not teach the claim as a whole. 

Salas does not teach a hierarchical arrangement of "rooms", but rather a room (eRoom 
24) which has a hierarchical arrangement of objects (pages 27, files 29, and database objects 28.) 
Several eRooms 22 are referenced in directory 22 from server database 20, but these are not 
arranged in a hierarchical structure. 

Cutler does not teach, inter alia, that access at any level of authority to a subroom is 
enabled only for those authorized to access the root room, together with a third access control 
(readers field) on the forward pointer to control whether the link to a child room will be enabled 
in its parent room for a specific user. 

While Maurille does teach forward and reverse pointers, Maurille only refers to a data 
schema including users, not rooms in collaboration space. 

Building on these distinctions with respect to the references taken individually, applicant 
traverse their combination. 

Applicants further contend that these teachings are not from a common domain such that 
teachings may be combined as the Examiner asserts. Typical of the Examiner's rationale, based 
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on applicant's own disclosure and using the claims as a roadmap, for combining these references 
is the following: 

"It would have been obvious to one of ordinary skill in the art... to modify Salas to 
operate a collaborative workspace for message communications between members as 
taught by Maurille, and to modify Salas to enable utilization of standard object oriented 
techniques for collaborative space processing such as pointers to objects containing 
access control lists (ACLs) and controlling access to objects as taught by Cutler.... to 
employ Maurille in order to optimize message processing and display capabilities for a 
networked collaborative communications environment (see Maurille col. 6, lines 13- 
16...), and to employ Cutler in order to efficiently enhance security by providing limited 
visibility of computer resources and protecting data integrity (see Cutler, col. 1 ,lines 47- 
53...). 

The above statement falls short of demonstrating that Salas, Maurille and Cutler teach 
applicants claims. That is, various teachings are drawn from these references in an apparent 
attempt to show all of the elements of applicant's claims, yet they fail to do so at the level of 
specificity set forth in applicants claims, as will be more fully explained below. 

Further, these references are in different fields, or domains. Specifically, Cutler refers to 
objects within an operating system domain, which is not the same domain as collaboration space. 
Maurille contains no reference to rooms in collaboration space. The generic use of access 
control on objects in an operating system taught by Cutler does not map, to those of ordinary 
skill in the art, to the specific claimed configuration of access controls on rooms and subrooms 
which are places within collaboration space having access control lists in each room and readers 
fields on forward pointers between rooms. Salas refers to an E-room, which is not the same as 
applicants collaboration space. The Salas E-room is a database with tables on a server, but not a 
plurality of E-rooms. Applicants collaboration space does not refer merely to a database on a 
server, but rather to a construct that has a plurality of rooms linked in such a way that a quick 



place (room) includes a plurality of quick places (rooms) double linked with access control on 
each parent place, each child place, and each forward pointer linking these places. 
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Applicants collaboration space comprises a root place including a plurality of additional 
places (subrooms) linked by the double linked (forward and reverse pointers) construct set forth 
in the claims, with access control on the root place, each subroom, and on the forward pointers 
which, in the specific combination set forth in the claims, support increased, decreased, and 
maintained (the same) access to the subroom as that allowed on a parent room, and that access at 
any level of authority to a subroom is enabled only for those authorized to access the root room, 
together with a third access control provided on forward pointers to control whether the link to a 
child room will be enabled in its parent room for a specific user. 

The Cutler reference is characterized by the Examiner as teaching "...the usage of object 

oriented technology utilizing access control list techniques for collaborative space management" 

(Office Action, page 10). Applicants agree that Cutler teaches access control on objects in an 

operating system domain, but traverse the suggestion that Cutler teaches such for collaborative 

space management. The Examiner refers (Office Action, page 12) to the following from Cutler: 

"In addition to visibility control, access to each object is controlled through an access 
control list which specifies the processes authorized to access the object, and the types of 
access that are allowed." [Cutler, Col. 2, lines 27-30.] 

"Each object 822 has access control information that describes the access rights needed 
by a user to gain access to a resource. The object header 820 contains the access control 
information." [Cutler, Col 22, lines 65-67.] 

"Any process, including the top level process, can cause the creation of additional 
processes, called subprocesses or child processes. Any process which creates another 
process is referred to as a parent process." [Cutler, Col. 5, lines 21-25.] 

There is no teaching in Cutler, nor in Cutler in combination with Salas and Maurille, that 
a second access control list is provided for a subroom (each room and subroom is a separate 
quick place in a collaboration domain) in a hierarchy of rooms (or quick places) so as to enable 
increased, decreased, and maintained (the same) access to the subroom as that allowed by the 
access control list on the parent room, and that access at any level of authority to a subroom is 
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enabled only for those authorized to access the root room, together with a third access control 

(readers field) on the forward pointer to control whether the link to a child room will be enabled 

in its parent room for a specific user. 

In Applicants' invention, an access control list for the place in collaboration space (that is, 

the root place, or room) is used for management of security of all sub-rooms within that space. 

That is, access (as distinguished from level of access: reader, manager, etc.) to sub-rooms within 

a place is limited to only those individuals listed in the access control list for the place (that is, 

the highest room in the hierarchy). Thus, Applicants' invention provides a restrictive control 

over who may become a member of the various rooms within a place (that is, to whom managers 

can give access to rooms within the place.) This list of people is in the place main or root room 

of the hierarchy of rooms. A manager or author can only add to the access control list of a room 

or subroom individuals who are listed in the access control list of the root room of the hierarchy. 

This structure is brought out in the following references from the specification. 

"Referring again to Figure 6, eight QuickPlace extensions 160 are enhancements made to 
the Domino web server 132 in order to support a QuickPlace application. These 
extensions 160 are enabled only for QuickPlace URLS; that is, they are enabled for URLs 
that are targeted against a particular QuickPlace. These extensions are: (1) shared design 
elements, (2) database linkage, (3) commands, (4) publish and draft model, (5) security 
and authentication, (6) forms and fields, (7) decoration model), and (8) graphics server." 
[Page 56, line 13 to page 57, line 1. Emphasis added.] 

"(2) Database linkage enables the grouping of a number of databases in a hierarchical 
way. A place is a collection of databases, and these need to be represented in a parent 
child relationship. Data notes represent the hierarchy to the database. There is a data 
note in the parent database, and there is a data note in the child database. The use of data 
notes for these QuickPlace extensions as a way of representing their functionality has the 
benefit that there are many ways of manipulating them, whether it's with Java or forms or 
the Notes designer. [Specification, page 57, lines 12-21.] 

"(5) The security and authentication QuickPlace extension is consistent with the 
QuickPlace model, which provides three levels of security or roles: reader, author, and 
manager. There exists a member directory for each place. What this means is that each 
place has its own set of members that visit it. The Domino server is modified to perform 
local authentication against that directory, making places very portable, self-contained. 
And they don't collide with other members in other places. A user, having control of his 
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own place member directory, set his own security for access to that directory. [Page 59, 
line 15 to page 60, line 1. Emphasis added.] 

"...a collaborative environment to be set up without administrative support, that is by 
members of the team itself, using a familiar and easy to use browser user interface. 
Members of the team, acting with manager or author authority, and using such a browser 
interface without involving administrative or application development support, need to be 
able to set up a folder or room for each project element..." [Specification, page 5, lines 7- 
15. Emphasis added.] 

"A room is created from a default room type template, PageLibrary.ntf, which provides 
indexing infrastructure for maintaining the pages in a room, and also security and 
authentication features so that access to a room can be limited to a subset of team 
members." [Specification, page 55, line 16 ff. Emphasis added.] 

Applicants contend that nowhere does Salas, Maurille, or Cutler teach that membership in 

an access control list control on a specific subroom in collaboration space is limited to members 

included in the access control list for the collaboration space. Thus, the reference to Col. 13, 

lines 31-34 of Salas states: 

"...each object may be provided with a field or fields which identify users that may open, 
view, and edit the object." 

"Users" is not limited, apparently, to "members", as the latter may be identified for the 
place as distinguished from objects within the place. As noted above, Cutler does not provide 
this missing element from Salas. 

Applicants invention provides a double linked list for linking rooms together in 
collaboration space, with access control list control on rooms and access control list control on 
forward pointers, or child pointers , to child rooms. 

This structure is illustrated in Figures 10 and 11 of applicants' specification, which are 

described as follows: 

Referring to Figure 10, QuickPlace rooms 201-204 and 210 are connected by forward 
and- backward pointers 205-209 and 211, and these enable the security of each room to 
be independently managed. Each room has its own security: that is, the identity of each 
user allowed to enter the room and that users security level : the three levels being reader, 
author, manager. This is held in an access control list which is a part of each room. 
While an individual, say Steve, has reader access (R) to the library 204, he can have 
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author (A) access to a subroom 211. This enables a subroom 211 to have increased/ 
maintained, or decreased access authority for a particular individual with respect to its 
parent room 204. Only individuals with access to a parent 204 can access a subroom 210, 
but that subroom 210 can have changed access for the subroom 210 for these individuals. 
Previously, security could not be increased in subrooms 210 with respect to a parent 
room 204. 

A database access control list (ACL) specifies who can or cannot access the database. 
For users who can access a database, access levels and roles determine the specific 
actions they can perform — for example, creating or deleting documents. Document 
access fields (Readers and Authors fields), in conjunction with the database ACL, control 
who can read or modify specific documents. Thus, to limit access to specific documents 
created from a form, a readers field is included. A readers field explicitly lists the users 
who can read documents created from the form. If a form has an access list, names from 
the readers field are added to the form access list. Otherwise, the readers field controls 
access to documents created from the form. Entries in a readers field cannot give a user 
more access than what is specified in the database access control list (ACL); they can 
only further restrict access. An authors field works in conjunction with author access in 
the database ACL. Listing users in an authors field expands access rights by allowing 
listed users to edit documents they create. Entries in an authors field cannot override the 
database access control list; they can only refine it. Authors fields affect only users who 
have author access to the database. 

Referring to Figure 11, forward pointers 205, 209 are secure . Security, in this context 
provides that forward pointer 205 to project A 203 carries the same security as that of 
project A 203, and anyone viewing main room 201 who is not entitled to access project A 
203 will not see room 203 listed in parent room. QuickPlace does not show a user things 
or objects to which the user does not have access. In past, such objects were shown, but 
were greyed out or otherwise managed so that user access was inhibited. Forward 
pointers, therefore, include room name field 212, address to database name field 213, and 
readers field 214, which includes a table of user identifiers 215 for each user permitted to 
access the room, with corresponding access authority 216 for each such user, which may 
be manager, author, or reader. [Applicants' specification, pages 48-50.] 

None of the references cited, taken individually or in any combination, teaches this 
structure of a double linked list for linking rooms together in rooms (places) in collaboration 
space with ACL security on each room (place in collaboration space) and ACL security (readers 
fields) on forward pointers in the double linked list. 

The Examiner refers (Office Action, page 8) to Salas col. 13, lines 32-34 and col. 14, 
lines 37-39 as teaching a "readers field for providing access control list control on said 
forward pointer." [Office Action, page 3.] Applicants traverse. This is what Salas teaches: 
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"For example, each object may be provided with a field or fields which identify users that 
may open, view, and edit the object." [Salas, Col 13, lines 32-34.] 

"Since every file and eRoom item is represented as an object in the database, access of 
users to each item can be controlled by entries in the database schema. For example, 
every eRoom may be represented by a table which has as one or more of its fields, a list 
of members that are entitled to enter the eRoom." [Salas, Col. 14, lines 37-42.] 

Applicants assert that there is no teaching here of an access control list, or readers field, 
on a specific forward pointer from a parent room to a child room, which ACL or readers field is 
distinct from the ACL for either the parent or child room. 

Applicants structure of access control elements provides a readers field as part of the 
pointer which is distinct from the ACL on either the parent or the child room, and is an ACL 
control on the pointer itself used to specify whether a pointer to a child room (place) is enabled 
in its parent room (place). 

Cutler teaches access control on objects genetically, but does not teach using such on 
forward pointers between rooms in collaboration space, as previously stated. 

The Examiner refers to Maurille as teaching forward pointers identifying a child room, 
but is silent as to the existence of an ACL control on that pointer [Maurille, Col. 6, lines 44-57]. 
However, applicants note, Maurille has no teaching of "room" entities, and only refers to a data 
schema including users, not rooms in collaboration space. 

Thus, neither Salas nor Maurille nor Cutler disclose or teach this aspect of the claims. 
That is, applicant argues, the combination of Cutler, Salas and Maurille does not teach ACL 
control specific to forward pointers in the hierarchical structure of rooms in collaboration space 
in addition to ACL control on the parent and child rooms within that space. 

That Salas does not teach a double linked list with ACL security on forward pointers in 
addition to ACL security on the rooms is apparent from examination of Salas Figure 1, which 
does not show forward and reverse pointers between rooms. In Salas, there is no teaching of 
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forward and reverse pointers linking rooms with ACL security on those forward pointers, as 
distinguished from and in addition to security on the rooms. While Maurille may disclose 
forward and reverse pointers, none of Cutler, Maurille or Salas teach ACL security on the 
forward pointers. Cutler's generic teaching of ACL on objects in an operating system domain 
does not teach the specific configuration of ACL controls on rooms and pointers within a 
collaboration space domain. 

Maurille is cited by the Examiner as teaching databases and pointers linking them, and 
Applicants agree that such is taught. Cutler is cited by the Examiner as teaching access control 
lists, and Applicants agree that such is taught. Applicants do not claim they invented forward and 
reverse pointers between objects in a hierarchy, nor are they claiming they invented access 
control lists. Rather, Applicants invented a hierarchy of rooms to create a collaboration space 
with a specific protocol of access control lists, including ACL lists on rooms and additional ACL 
control specifically on forward pointers used for management of security of rooms within that 
collaboration space. Neither Maurille, Cutler, nor Salas, taken separately or in combination, 
teach that protocol. 

Rejection of Claims 1 and 2 Under 35 U.S.C. 103 

The discussion above of claims 3-7, 9, 13 and 15, applies equally to claim 1. The 
primary distinction in claim 1 with respect to the claims previously discussed is the provision for 
"a document readers field for a document containing data in said subroom being a members 
object for identifying a subset of members of said place authorized to access a subroom who are 
also authorized to access said document," as is described at page 49, lines 1-18 of the 
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specification. The Examiner cites Salas, col. 13, lines 32-34. Applicant concurs. Consequently, 
claims 1 and 2 will stand with claims 3-7, 9, 13, and 15 on the distinctions previously discussed. 



Rejection of Claim 10 Under 35 U.S. C. 103 

Claim 10 varies from the claims previously discussed in that it is directed to the creation 
of a child room. This includes initially providing in a readers access field (195) for a child room 
created from a form those users identified in a form access list identifying users authorized to 
read rooms (such as 202) created from that form (page 49, lines 3-9) ; and limiting reader access 
in the readers access field (195, for subroom 210) to the child room (210) for a specific user to 
no more than the access granted that specific user in the first access control list (195, for main 
room 201) (page 49, lines 9-12). 

On this point, the Examiner refers (Office Action, page 21) to Salas, col. 13, lines 32-34 
and col. 14, lines 37-39, quoted above. 

Applicant argues that there is no teaching in these references to Salas, or elsewhere in any 
of the references, of the feature here being claimed. That is, creating a room from a form, which 
form has an associated form access list identifying those users authorized to access a room 
created from that form, in combination with the other limitation of the claims including, 
specifically, the readers field on forward pointers linking to and from the room created from that 
form, as previously discussed. 



Rejection of Claim 3 Under 35 U.S.C. 103 

Claim 3 varies from claims 9,13, and 15 by hot specifically reciting the displaying of a 
parent room, which limitation is included in its dependent claim 7, and by a more precise 
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rendition that the ACL on a child room can only included users identified as authorized to enter 
the root place. The most relevant distinctions in claim 3 with respect to the Salas, Maurille, and 
Cutler references are those previously discussed with respect to claims 9, 13, and 15, so claim 3 
and its dependent claims 4-7 stand with them. 



Request 

Applicant requests that the Board reverse the decision of the Examiner to reject claims 1- 
7,9-10, 13, 15. 

Having overcome all of the outstanding rejections, Applicants respectfully submit that 
the subject application is now in condition for allowance. Applicants believe that all of the 
pending claims have been addressed. However, the absence of a reply to a specific rejection, 
issue or comment does not signify agreement with or concession of that rejection, issue or 
comment. In addition, because the arguments made above may not be exhaustive, there may be 
reasons for patentability of any or all pending claims (or other claims) that have not been 
expressed. Finally, nothing in this paper should be construed as an intent to concede any issue 
with regard to any claim, except as specifically stated in this paper. 
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In light of the above remarks, Applicants respectfully assert that the subject application is 
in condition for allowance. While Applicants respectfully assert that the subject application is 
now in condition for allowance, the Examiner is invited to telephone Applicants' attorney (617- 
305-2143) to facilitate prosecution of this application. Please apply any charges or credits to 
deposit account 50-2324. 



Respectfully submitted, 



Dated: 04 November 2009 /Brian J. Colandreo/ 

Brian J. Colandreo 
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